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Abstract 

We identify two unreasonable, though standard, assump- 
tions made by database query optimizers that can adversely 
affect the quality of the chosen evaluation plans. One as- 
sumption is that it is enough to optimize for the expected 
case — that is, the case where various parameters (like avail- 
able memory) take on their expected value. The other as- 
sumption is that the parameters are constant throughout 
the execution of the query. We present an algorithm based 
on the "System R" -style query optimization algorithm that 
does not rely on these assumptions. The algorithm we present 
chooses the plan of the least expected cost instead of the plan 
of least cost given some fixed value of the parameters. In 
execution environments that exhibit a high degree of vari- 
ability, our techniques should result in better performance. 

1 Introduction 

A database query is specified declaratively, not procedurally. 
Given a query, it is the job of the DBMS to choose an ap- 
propriate evaluation plan for it. This task is performed by 
a cost-based query optimizer. In theory, the task of the op- 
timizer is simple: it performs a search among a large space 
of equivalent plans for the query, estimates the cost of each 
plan, and returns the plan of least cost. 

In practice, things are not so simple. There are two ma- 
jor problems: (1) there are far too many possible plans for 
an optimizer to consider them all, and (2) accurate cost es- 
timation is virtually impossible, since it requires detailed a 
priori knowledge of the nature of the data and the run-time 
environment. Because query optimization is such a criti- 
cal component of a database system — queries are typically 
optimized once and then evaluated repeatedly, often over 
many months or years — much effort has gone into dealing 
well with these problems. The query optimizer has become 
one of the most complex software modules in a DBMS. 

Dynamic programming technique s are typically used to 
deal with the first problem [ SAC^79[ |, although randomized 



algorithms have also been proposed |3wa89, IK90|. As we 
shall see, they apply in our approach too, so we focus here 
on the second problem. To accurately estimate the cost of 
executing a particular plan, we need to estimate the values 
of various parameters. Typically, these parameters can be 
divided into three categories: 

1. Parameters representing properties of the data (car- 
dinalities of tables, distributions of values, etc.). The 
DBMS typically maintains estimates of these parame- 
ters. 

2. Parameters representing properties of the query com- 
ponents (e.g., sizes of groups, selectivities of predi- 
cates). Much research has focused on how to make ac- 
curate estimates of selectivities and r esult size s. These 
techniques typically use histograr ns [PIHS96 (part of 
the data properties) or sampling | LNSS93| . 
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3. Parameters representing properties of the run-time en- 
vironment (e.g., amount of available memory, proces- 
sor speed, multiprogramming level, access character- 
istics of secondary storage). These are gathered from 
observations of the realistic deployment environments. 

If the value of a parameter cannot be exactly predicted 
(which is almost always the case, especially if it can change 
even during the execution of a query), it can at best be 
modeled by a distribution. Current optimizers simply ap- 
proximate each distribution by using the mean or modal 
value. They then choose the plan that is cheapest under the 
assum ption that the parameters actually take these specific 
values [SAC^79| and remain constant during execution. We 
call this the least specific cost (LSC) plan. 

We propose a very different approach in this paper. We 
view the query optimizer as an agent trying to make a de- 
cision; it must choose among different plans. The standard 
decision-theoretic app roach i s to choose a plan that maxi- 
mizes expected utility [Res87|. Here utility is essentially the 
negation of the cost: the lower the cost, the more attrac- 
tive the plan. Thus, we argue that rather than choosing the 
LSC plan, query optimization algorithms should be directed 
towards finding the plan of least expected cost (LEG). 



1.1 A Motivating Example 

The following example should help motivate the use of LEC 
plans. For pedagogical reasons, we focus in this example, 
and throughout most of the paper, on only one parameter, 
the amount of available memory, which i s know n to be dif- 
ficult to predict accurately in practice | Loh98 . Thus we 



assume that everything else (e.g., predicate selectivities) is 
known. We consider the case of more than one parameter 
in Section 3.C . 



Example 1.1: Consider a query that requires a join be- 
tween tables A and B, and the result needs to be ordered 
by the join column. A has 1,000,000 pages, B has 400,000 
pages, and the result has 3000 pages. Consider the following 
two evaluation plans: 

• Plan 1 : Apply a sort-merge join to A and B. The op- 
timizer cost formulas tell us that if the available buffer 
size is greater than 1000 pages (the square root of the 
larger rel ation), the join requires two passes over the 
relations l ^haSet . If there are fewer than 1000 pages 
available, it requires at least another pass. Each pass 
requires that 1,400,000 pages be read and written. 



• Plan 2: Apply a Grace hash-join [3ha86| to A and B 
and then sort their result. We know that if the avail- 
able buffer size is greater than 633 pages (the square 
root of the smaller relation), the hash join requires two 
passes over the input relations. The subsequent sort 
also incurs additional overhead, especially if the data 
does not fit in the buffer. 

If the available buffer memory is accurately known, it is easy 
to choose between the two plans (Plan 1 when more than 
1000 pages are available and Plan 2 otherwise). However, 
assume that the available memory is estimated to be 2000 
pages 80% of the time and 700 pages 20% of the time. (This 
distribution is obtained by observing the actual query execu- 
tion environment.) Current optimizers assume one specific 
memory value (in this case, 2000 pages as a modal value, or 
1740 pages as a mean value). In either case, the plan chosen 
would be Plan 1. However, we claim that Plan 2 is likely to 
be cheaper on average across a large number of evaluations. 
The intuition is simple: In 80% of the runs. Plan 2 is slightly 
more expensive than Plan 1 (the extra expense arises in sort- 
ing the small result), whereas in 20% of the cases. Plan 1 
is far more expensive than Plan 2 (the extra expense comes 
from an extra pass over the data). On average, we would 
expect Plan 2 to be preferable. | 

Example |l.l| shows the flaw that arises if parameter dis- 
tributions are characterized by a single expected value: The 
least cost plan found based on this value is not necessarily 
the plan of least expected cost. Indeed, whenever there are 
discontinuities in cost formulas (as is the case with database 
join algorithms), such an effect is likely to arise. 

1.2 Contributions 

The contributions of this paper are: 

1. We introduce LEC plans, which are guaranteed to be 
at least as good as (and typically better than) any 
specific LSC plan. 

2. We show how LEC query optimization can take into 
account parameters that have a constant value dur- 
ing any specific query execution [static parameters), 
and also those that vary during execution [dynamic 
parameters). Moreover, it can be applied either at 
compile-time or at start-up time. 



plan. The extension increases the cost of query opti- 
mization by a factor depending on the granularity of 
the parameter distribution. 

4. We extend LEC query optimization to handle queries 
where the selectivity of each predicate is a parameter 
modeled by a distribution. 

Depending on the actual distribution of parameters that 
arises in practice, the LEC plan can be much more efficient 
on average than any specific LSC plan. The greater the 
run-time variation in the values of parameters that affect 
the cost of the query plan, the greater the cost advantage 
of the LEC plan is likely to be. If such parameter distri- 
butions are common, it should be well worth implementing 
this approach in commercial database systems. 

The rest of this paper is organized as follows. In the 
next section, we review the traditional approaches to nuery 
optimization and discuss related work. In Section |3[ we 
introduce LEC query optimization and discuss how LEC 
plans may be generated in practice by a typical DBMS. To 
this end, we consider extensions to the widely used System R 
query optimization algorithm. Our algorithms apply both 
in the case where parameters are static and (under some 
simplifying assumptions) the case where they are dynamic. 
In Section W we discuss the simplifying assumptions we make 
in the paper and possible future directions. 

2 Background 

2.1 Standard Query Optimization 

There are three basic approaches proposed for query opti- 
mization algorithms: 

• Bottom-Up Optimization: This is a synthetic approach 
in which a suitable plan is created by starting from 
the stored tables and building increasingly larger plans 
until a plan for the entire query is formed. 

• Top-Down Optimization: This is a divide-and-conquer 
approach in which the entire query is divided into 
pieces, each piece is optimized, and then the pieces 
are put together to form the query plan. 

• Transformational Optimization: This starts with some 
valid complete query plan, and repeatedly transforms 
it into a different valid complete plan. At every stage, 
the plan of least cost is retained. 

Every query optimizer uses some element of each approach. 
Typically, a query is divided into a graph of "query blocks" 
and some transfor mationa l optimizations are performed on 
the query blocks PHH92 |. Each query block in the graph 
is then typically optimized almost independently. A spe- 
cific kind of query block, the SELECT-PROJECT- JOIN or 
SPJ block, has received a lot of attention, because it oc- 
curs in many queries and involves expensive join operations. 
The optimization of an SPJ block itself could use any of 
the three basic approaches. Most commercial database sys- 
tems use a bottom-up optimizer based on dynamic program- 
ming. This appr oach was first suggested in the System R 
project [3AC"'"7!:]. We now briefly describe how it works. 
In later sections of the paper, we describe variations of this 
algorithm that find LEC plans. 



3. 



We show how traditional dynamic programming query 
optimizers can be easily extended to produce the LEC 



2.2 The System R Approach 

Suppose we are given n relations, Ai, . . . , An, whose join we 
want to compute. For ease of exposition, assume that there 
are join predicates between every pair of relations. (This is 
not very realistic, but one can always assume the existence 
of a trivially true predicate.) Three basic observations in- 
fluence the algorithm: 

f. Joins are commutative. 

2. Joins are associative. 

3. The result of a join does not depend on the algorithm 
used to compute it. Consequent W, dynamic program- 
ming techniques may be applied.iH 

The System R optimizer also applies some heuristics that 
further limit the space of plans considered. Of particular 
relevance to this paper are the following two heuristics: 

1. Only binary join algorithms are considered. Conse- 
quently, a three-relation join evaluation plan involves 
the combination (i.e., join) of a two-relation join result 
and a stored relation. 

2. To find the best plan for a fc-relation join, the only 
plans considered are those that first involve joining 
some subset of — 1 of these relations and then adding 
in the fcth. Other possible approaches (for example, 
considering the best plan for joining a subset of — 2 
of the relations, joining the remaining two relations, 
and then joining the results) are not considered. 

Given these two heuristics. System R is essentially trying to 
find the permutation vr of {1, . . . , 71} that produces the best 
plan of the form 

((• • ■ ((A^(l) 1X3 v4^(2)) 1X1 A^(3)) ■ ■ •) 1X3 A^(„)). 

Such plans are called left-deep plans. 

Conceptually, we can think of the System R optimizer 
as working on a dag with a single root (node of indegree 0) . 
Each node in the dag is labeled by a subset S of {1, . . . , n}. 
The label of the root is the empty set. The nodes at depth 
k are labeled by the subsets of {1, . . . ,n} of cardinality k. 
There is an edge from a node at depth A: — 1 labeled by S" to 
a node at depth k labeled by S iff 5' C 5*. Fix a setting of 
the parameters. Associated with the node labeled S is the 
best left-deep plan to compute the join over S (i.e., cxiigg Ai, 
the join of the relations with indices in S) for that setting 
of the parameters. This plan is determined inductively as 
follows. Initially, the algorithm determines the best plan 
to access each of the individual relations. In the next step, 
the algorithm examines all possible joins of two relations. 
For each pair of relations, several different join algorithms 
are considered and the cheapest evaluation plan is retained. 
Assume inductively that we have associated with each node 
up to depth k the plan for computing the join associated 
with that node. To compute the best plan for a node S at 
depth A; -1-1, consider each j £ S and let Sj = •S' — {j} and let 
Bj =[xiigs^ Ai. For each j, let Cj be the sum of the cost of 
the best plan for accessing Aj , the cost of the best plan for 



"^It is well-known that this is not quite accurate; the physical prop- 
erties ("interesting orders") of the join result depend on the specific 
plan used to create it. This require s simple cvtensions of the opti- 



computing Bj (which we have already determined) , and the 
cost of the best plan for computing Bj txi Aj. We then find 
the j for which Cj is minimal. This gives us the the best 
plan for computing cxiigg Ai as well as its cost. Note that 
at phase (fe + 1), only results from phase k are utilized. At 
phase n, we label the root by the best plan to compute the 
join (and its cost). Although this approach takes time and 
space exponential in n, n is usually small enough in practice 
to make this approach feasible. 
To summarize, we have: 

Theorem 2.1: The System R optimizer computes the LSC 
left-deep plan for a specific setting of the parameters. 



(We remark that a formal proof of Theorem 2.1 can be pro- 
vided along the lines of the proof of Theorem 3.3 given be- 
low.) 

2.3 Previous Work on Dealing with Uncertainty of Pa- 
rameter Values 

It is widely recognized that query optimizers often make 
poor decisions because their compile-time cost models use 
inaccurate estimates of various parameters. There have been 
several efforts in the past to address this issue. We catego- 
rize them as (a) strategies that make decisions at the start 
of query execution and (b) strategies that make decisions 
during query execution. 

Let us assume that there are some parameters that can- 
not be predicted accurately at compile-time, but that are 
accurately known when a query begins execution. An exam- 
ple of such a parameter is the number of concurrent users. 
Let us further assume that the value of this parameter stays 
constant during the execution of the query. In this case, we 
are aware of three kinds of strategies: 

• A trivial strategy is to perform query optimization just 
before query execution. This is the approach used in 
database systems like lUustra 1 11194 1, but is not par- 
ticularly efficient, since the query may be executed re- 
peatedly. 

• Another strategy is to find the best execution plan for 
every possible run-time value of the parameter. This 
requires much additional work at compile-time, but 
very little work at query execution time (a simple ta- 
ble lookup to find the bes t plan for the current param- 
eter value). In [tNSS92], the authors suggest using 



randomized optimization to reduce the compile-time 
optimization effort. 



• I GC94 1 suggests a hybrid strategy that performs some 
of the search activity at compile-time. Any decisions 
that are affected by the value of the parameter are 
deferred to start-up time through the use of "choice 
nodes" in the query evaluation plan. 

For parameters that cannot be accurately predicted at 
the start of query execution (like predicate selectivities) , 
these strategies are clearly inapplicable. We are aware of 
four other strategies that address this case; all involve a po- 
tential modification of query execution. 



mization algorithm, as described in SAC 7S| |. Wc ignore this issue 
here, since our solutions apply without change in the presence of these 
extensions. 



• [KD98] proposes using a regular query optimizer to 
generate a single plan, annotated with the expected 
cost and size statistics at all stages of the plan. These 
statistics are affected by the choice of parameter value. 
During actual query execution, the expected statistics 
are compared with the measured statistics. If there is a 



significant difference, tlie query execution is suspended 
and re-optimization is performed using tfie more accu- 
rate measured value of the parameter. 



I Ant95 ] implements an interesting variant of this idea. 
In order to execute a query, multiple query plans are 
run in parallel. When one plan finishes or makes sig- 
nificant progress, the other competing plans are killed. 
This strategy assumes that resources are plentiful (and 
so can be wasted), and is applied only to subcompo- 
nents of the query (typically to individual table ac- 
cesses) . 



|QFA98| examines a very specific kind of parameter 
variation: the cost of accessing a table across an oc- 
casionally faulty network, such as the Internet. Their 
strategy reoptimizes the query when the system rec- 
ognizes during query execution that the source of a 
table is not available. Instead of restarting the query 
like ||KD98^ , the remainder of the query plan is ad- 
justed ("scrambled" ) to try to make forward progress. 



|3BM93| focuses on uncertainties that can be reduced 
by sampling (more specifically, the uncertainty of the 
selectivity of a predicate) . They use decision-theoretic 
methods to pre-compute scenarios where it may be 
worthwhile to do sampling (since sampling itself comes 
with a cost). If such a scenario arises, they do the 
sampling and modify the plan as appropriate, given the 
result of the sampling. We remark that this approach 
is the one perhaps closest to that advocated here in its 
view of query optimization as a decision problem and 
its aim of minimizing expected cost. The techniques of 
can be combined with those suggested here. 



Note that these approaches all involve making some deci- 
sion after compile-time. The way they deal with uncertainty 
is to wait until they have more information. We deal with 
uncertainty by treating the parameters as random variables, 
so our approach can be applied completely at compile-time, 
as well as at start-up time or run-time. When our approach 
is applied at compile-time, the size of the query plan created 
does not increase as with some of these approaches. 

3 LEC Query Optimization 
3.1 The Formal Model 



Fix a query. Like [INSS92|, we start by assuming that there 
is a cost function (D that takes two arguments, a plan p and a 
vector V of values of relevant parameters, and returns a cost. 
Intuitively, (D(P, v) is the cost of executing plan p under the 
assumption that the relevant variables take the values v. 
The standard (LSC) approach is to choose a fixed value of 
V — usually the expected value of the parameters — and find 
a p with the least cost. We assume instead that there is a 
probability measure on the space V of possible values of the 
parameters. Given (D and Pr, we can compute the expected 
cost for each plan p. Let Ec(P) denote the expected cost of 
p (with respect to cost function C and probability Pr); as 
usual, we have 



Ec(P) = ^C(P,v)Pr(v) 
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If the distribution Pr is an accurate model of the distribu- 
tion of the parameters that is encountered at run-time, and 
the cost estimates (D are accurate then, by definition, the 
expected execution cost of the LEC plan is at least as low 
as that of any specific LSC plan. 

The goal of finding the LEC plan makes sense both at 
compile-time and at start-up time. At start-up time, the 
distribution of parameters will typically be different from 
the one at compile-time. For some parameters, the distribu- 
tion may be more concentrated around one value. However, 
it is unlikely that there will be complete information about 
all the values of the relevant parameters, even at start-up 
time. This is particularly true about parameters whose val- 
ues may change as we execute the query. Note that the LEC 
approach applies to such dynamic parameters as well. We 
need to use a probability distribution over all possible se- 
quences of parameter values during the execution and then 
again compute the plan with least expec ted cost. We explore 
the details of this approach in Section ^.5[ Until then, we 
assume that parameters do not change value during query 
execution. 

This leads to some obvious questions: 

1. How do we get the probability distributions? 

2. How do we get the cost estimates? 

3. How do we compute the LEC plan? 

With regard to the first question, as we noted in the in- 
troduction, the DBMS in practice is constantly gathering 
statistical information. We believe that the statistics can 
be enhanced to provide reasonable estimates of the relevant 
probabilities, although this is certainly an area for further 
research. For the purposes of this paper, we assume without 
further comment that the probabilities are available. As for 
the second question, we are making the same assumptions 
about costs that are made by all standard query optimizers. 
Finally, with regard to the last question, in the remainder 
of this section, we provide a number of ways to modify the 
standard optimizers so as to produce the LEC plan (or a 
reasonable approximation to it). These approaches vary in 
their need to modify the underlying query optimizer, the 
quality of the plan produced, and the underlying assump- 
tions about the distribution. 

3.2 Algorithm A: Using a Standard Query Optimizer as a 
Black Box 

For ease of exposition, we assume in the next few sections 
that the only relevant parameter is the amount of available 
memory, so we take v to represent this quantity. This as- 
sumption is dropped in Section 3.C We assume that we can 



Following standard decision-theoretic approach, our goal is 
to find the LEC plan, the one whose expected cost is least. 



partition the distribution of the amount of available memory 
into a small number (say b) of buckets such that the cost of a 
plan is likely to remain relatively constant within a bucket. 
For example, in Example the appropriate buckets are 
the intervals [0,633), [633,1000), and [1000, oo). Choosing 
the buckets appropriately can be nontrivial; we discuss this 
issue in more detail in Section ^.7[ We can identify the stan- 
dard approach to doing query optimization with the special 
case where there is only one bucket. Once we have chosen 
the buckets, we pick a representative from each bucket; call 
them mi, . . . , rrit- Finally, we assume that we have a proba- 
bility measure Pr such that Pr(mi) characterizes how likely 
we are to run the query in the ith bucket. 

Given these assumptions, there is a straightforward ap- 
proach to finding good approximations to the LEC plan that 



uses a standard query optimizer as a black box. Suppose we 
want to compute oa ■ • ■ xi A„. Assume that memory 
stays constant during the execution of the plan. 

Algorithm A 

For each value nii of the memory parameter, we run 
the optimizer under the assumption that rrii is the ac- 
tual amount of memory available. This gives us b can- 
didate plans. We then compute the expected cost of 
each candidate, and choose the one with least expected 
cost. 

As long as the expected value of memory used by the 
traditional LSC approach is one of the b possible values we 
consider (and, without loss of generality, we can assume it 
is), then we are guaranteed to end up with a plan whose 
expected cost is no higher than that of the plan chosen by 
the traditional approach. We assume that, in practice, the 
actual LEG plan will have a cost close to the optimal plan 
for some value nii of memory. To the extent that this is 
true. Algorithm A gives us a good approximation to the 
LEG plan. 

The cost of Algorithm A is the cost of b invocations of 
the optimizer, plus the cost of evaluating the expected cost 
of each candidate plan. Each candidate plan has n — 1 joins, 
and each has to be costed for 6 different memory sizes to 
determine the expected cost. There are b such candidates, 
leading to a total cost of 0((n — 1)6^), which should be much 
smaller than the cost of candidate generation, 0{bn2"~^). 
Gonsequently, the approximate cost of Algorithm A is b 
times the cost of a single optimizer invocation. 

Note that it makes sense to use Algorithm A at start- 
up time as well as at compile-time; we simply use the ap- 
propriate distribution over memory sizes when checking to 
see which candidate plan is best. We can also combine 
th ese ideas with the parametric query optimization approach 
of |INSS92|. We can precompute the best expected plan un- 
der aTuiniber of possible distributions (ones that give good 
coverage of what we expect to encounter at run-time), and 
store these expected plans, for use at query execution time. 

While this approach has the advantage of not requiring 
any change to the optimizer whatsoever, it has two major 
drawbacks. The first is that it requires us to prespecif y th e 
buckets (this point should become clearer in Section 3.7); 
the second is that it may not actually return the LEG plan. 
It is conceivable that a plan not optimal for any rrii actually 
does better on average than any candidate considered by the 
algorithm above. For example, the plan that is second-best 
for some memory size may do better on other memory sizes 
than the best plan for that memory size, and so may do 
better in expectation. We now present a simple modifica- 
tion of this approach that generates more candidate plans, 
although it has the disadvantage of requiring us to modify 
the basic query optimizer. 

3.3 Algorithm B: Generating More Candidates 

Suppose that rather than generating the best plan for each 
memory size rrii, we generate the top c plans, for some c > 
1. It is relatively straightforward to modify existing query 
optimizers to do this. For concreteness, we show how this 
can be done with System R. 

Algorithm B 

Assume inductively that we have associated with each 
node up to depth k in the dag the top c plans for com- 
puting the join associated with that node. To compute 



the top c plans for a node S at depth k + 1, consider 
each j G S and let Sj = S—{j}, as before. We consider 
the top c plans for computing the join over Sj and the 
top c plans for accessing Aj; combining them using 
each possible join method gives us the top c plans for 
computing the join over 5* if we join Aj last. 

While it seems that there are combinations of plans that 
need to be considered here for each join method, the actual 
number of combinations is lower. 

Proposition 3.1: It sujfices to consider at most c + clogc 
combinations of plans for each join method to produce the 
top c plans. 

Proof: Suppose si, . . . ,Sc are the top c plans for computing 
Sj (sorted in increasing order of cost) and ai, . . . , Oc are the 
top c plans for accessing Aj (again sorted in increasing order 
of cost). Note that the cost of the combination {si,ak) is no 
higher than the combination (s^/, a^/) if i < i' and k < k'; so 
there are (at least) ik — 1 combinations with cost no higher 
than {si,ak). Thus we only have to consider {si,ak) for 
ik < c, since ik > c implies we can get (at least) c plans at 
least as good as (si,afe). 

Note that ik < c implies i < c/k, so we only need to 
consider the top [c/fcj entries of the kth column if we arrange 
the combinations in a c x c matrix. Thus the total number 
of entries we need to consider is 



Recall that 



— dx = 1 + log c. 

X 



Thus the total number of entries we need to consider is at 
most c + c log c. I 

To compute the best c plans using a particular join method 
for joining Sj and Aj, we must first evaluate the cost formula 
for the join method. Note that all the c variants of each in- 
put have the very same properties, and so behave identically 
with respect to the cost formula. Gonsequently, the only dif- 
ference between the c-\- c log c combinations arises from the 
sum of the costs of the two input plans. Gonsequently, the 
cost of checking these combinations is expected to be small 
compared to the cost of evaluating a cost formula. By con- 
sidering all j £ S, we get j lists of c top plans. We then take 
the top c plans from the combined list. This extension can 
be easily implemented and is a relatively small and localized 
change to current optimizers. 

Theorem 3.2: Algorithm B computes the top c left-deep 
plans for each of the b choices of parameter values at ab 
times the cost of computing the single best left-deep plan for 
one specific setting of the parameters, for some small con- 
stant a > 0. 

Once we have the top c plans for each of the b memory 
sizes, we can then again compute the expected cost of each 
of these cb plans, and choose the plan of least expected cost. 
As we showed in the previous section, the computation of 
expected costs of candidate plans is small compared to the 
cost of candidate generation. In this case, the number of 
candidates is increased by a factor of c, but we still expect 



Algorithm B to be roughly b times as expensive as a single 
optimizer invocation. 

While Algorithm B generates more candidates (and thus 
is more likely to end up with a good approximation to the 
LEG plan) , it still does not necessarily end up with the LEG 
plan. As we now show, if we are willing to modify the basic 
query optimization algorithm further, we can produce the 
actual LEG plan. 

3.4 Algorithm C: A Generic Algorithm for Computing the 
LEC Plan 

We now provide a generic modification of the basic System R 
query optimizer that can directly compute the LEG plan, 
merging the candidate generation and costing phases. We 
assume inductively that we have associated with each node 
up to depth k in the dag the plan with least expected cost 
for computing the join associated with that node (as well as 
the expected cost itself) . We further assume that with each 
node we have associated a probability distribution over the 
possible memory sizes. Intuitively, this is the probability 
distribution over the available memory when we reach that 
node during an actual execution of a query plan containing 
the node as a subplan. If we assume that memory size does 
not change during the course of executing the plan, and 
that join operations are not pipelined in the plan, then the 
distribution is the same at every node. We do away with 
this restriction in the Section 3.5. 



Algorithm C 



Again, we proceed inductively down the dag. For each 
stored relation Ai, find an LEG access path for it. To 
compute the plan with least expected cost for a node 
at depth k + 1 labeled S, consider each j £ S and let 
Sj = S — {j}. The expected total cost of S is the 
expected cost of computing Sj (which, by assumption, 
we already have in hand) added to the expected cost 
of joining Sj and Aj, which we can compute given 
the probability distribution of available memory. If 
we consider a probability distribution over b different 
memory sizes, this computation requires b evaluations 
of the cost formula for the join algorithm. We retain 
the plan for S with the least expected total cost, dis- 
carding all the other candidates. 



Theorem 3.3: Algorithm C gives us the LEC left- 



Proof: The proof is a straightforward adaptation of the 
argument for the correctness of the basic System R algo- 
rithm, using the fact that expectation distributes over ad- 
dition. Suppose 5 is a nonempty subset of {1, . . . ,n}. Let 
Ps denote a left-deep plan for computing ixiigs Ai. We can 
conceptually think of Ps as consisting of a choice of j G 5, 
a plan Pg for accessing Aj, and, if 15*1 > 1, a plan Pg for 
computing Bj = fxii^Sj Ai and a plan Pg" for computing 



C(Ps,v) 
It follows that 
Et;(Ps 



= «^(Ps,v) 



Ec(Ps) 



+ C(Pf,v) + C(P^,v). 



(Ps) 



+ Ec(P£ 



Let Ps be the plan that Algorithm G outputs for S. We 

want to show that Ec(Ps) < Ec(Ps) for all Ps. We proceed 
by induction on \S\. 



For the base case we have 15*1 = 1. Suppose 5* = {i}. 

Then E<[;(Ps) < E<p(Ps), since Algorithm G will choose an 
LEG access path for Ai. Now assume that the claim holds 
for all S with \S\ = k. Let 5 be a subset of {l,...,n} 
with fc -I- 1 elements. For all j £ S, let P{j) be a plan 

such that P(j)^ = Ps,, P(j)^ = P{j}, and P(j)'^ is an 
LEG method to compute the join. It is clear from the de- 
scription of Algorithm G that Ps G {P{j) '■ j & S} and 

that Ec;(Ps) = min{P(j) : j £ S}. Suppose Ps is an ar- 
bitrary left-deep plan to compute ixiigs Ai. Suppose Ps 
computes ixiigSj Ai first. Thus Ps computes ixiigSj Ai. 
By the induction hypothesis and the definition of P(j), we 

see that E<c(Ps) > Ec(Ps,) = Ec(P(i)^). Furthermore, 

Ec(Pf) > Ec(P{,}) = Ec(P(j)^), since P^^} is an LEG 
access path. Finally, Ec(Pg') > Ec(P(j)'^), since P(j)^ is 

an LEG join method. Thus E(d(Ps) > Ec(P(i)) > E(d(Ps) 
as required. | 

If we assume that memory does not change as we execute 
the plan, then the cost of the computation is 6 times the 
cost of the standard computation using a single memory 
size. Again, Algorithm G works both at compile-time and at 
start-up time. And again, we can combine these ideas with 
those of parametric query optimization, precomputing the 
LEG plans under various assumptions about the probability 
distributions and storing them for use at start-up time. 

3.5 Dealing with Change During Execution 

So far we have assumed that the amount of available memory 
stays constant throughout the execution of the plan. This 
may not be so reasonable if the query takes a long time (on 
the order of minutes or more). During the execution, con- 
current new queries may start while old queries may finish. 
If we assume that available memory is mainly determined by 
the number of queries being run concurrently, then it may 
well change during the execution. 

To deal with dynamic memory changes, we assume a 
probability measure over the possible sequences of memory 
sizes. We then must evaluate each candidate plan with re- 
spect to this sequence and determine its expected cost. To 
keep the analysis from becoming too unwieldy, we assume 
that plan execution takes place in phases, each correspond- 
ing to a join in the plan. We assume that memory does not 
change during the execution of a phase, but can change be- 
tween phases. If we compute a join over n relations, there are 
n— 1 phases. Thus, we need to consider possible run-time en- 
vironments corresponding to each sequence of memory sizes 
of length n — 1. We need to use a probability distribution 
over all such memory size sequences. 

Where does this distribution come from? Perhaps the 
most natural assumption is to assume that we have some 
distribution over the initial memory sizes, and that there is 
a transition probability describing how likely memory is to 
change by m units, for each value of m. For simplicity, we 
assume that this transition probability depends only on the 
current memory usage, not on the time. This is a reasonable 
assumption for 24 x 7 systems in stable operational mode. 

Under these simplifying assumptions, we can apply Al- 
gorithm G presented in the previous subsection to calculate 
the LEG plan even with dynamic memory. We simply as- 
sociate the initial distribution with the root of the dag, and 
use the transition probabilities to compute the distribution 
associated with each node in the tree. We can then apply the 



Ec(P5) 
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Pr(|A,|) 
Pr(M) 



Figure 1: Distributions Needed at Each Node and What 
Depends on Them 



algorithm without change, since Algorithm C does not rely 
on the fact that v consists of a single memory size. Note, 
however, that the complexity of Algorithm C is clearly af- 
fected, since the parameter space is potentially much bigger 
(since if there are 6a/ memory values we consider, there are 
6m sequences of length n — 1). 

Theorem 3.4: Given the simplifying assumptions above, 
Algorithm C returns the LEG left-deep plan even in the pres- 
ence of dynamically varying parameters. 

Proof: While v now consists of a sequence of memory sizes, 
the proof of Theorem 3. J works here also, since that proof 



did not rely on the fact that v is a single memory size in 
any way. | 

3.6 Dealing with iVIultiple Parameters 

We have focused on only one parameter so far (i.e., the 
amount of available memory). In practice, we typically have 
to deal with a number of parameters. In this section, we 
consider the effect of multiple parameters on our algorithms 
(specifically, available memory and the selectivities of all 
the query predicates). Selectivities, in particular, are noto- 
riously uncertain. We believe that by representing the un- 
certainty by a probability distribution and computing the 
LEG plan, we ca n amelio rate some of the difficulty. Note 
that the ideas of |SBM93] for deciding when to sample may 
also be usefully applied here. We focus on the st atic case in 
this section. We can apply the idea from Section 3.5 to deal 
with the dynamic case. 

When the amount of available memory is the only un- 
certainty, we need only a single probability distribution at 
every node in the dag to allow us to compute the LEG plan. 
When there is more than one uncertain parameter, we may 
need to expand that to a joint distribution, whose size may 
grow exponentially as the number of parameters. Since in- 
dependence often holds in practice or is the default assump- 
tion of existing query optimizers, we assume for the rest of 
this section that all parameters of interest are independent. 
This simplifying assumption means that we can carry a sep- 
arate distribution for each parameter and avoid the expo- 
nential blow-up in the description of the joint distribution. 
If are some dependencies between the variables, but not too 
many, we can still d escribe the distribution succinctly using 



a Bayesian network [ Pea88 1 . We believe that the techniques 
that we present here will also be applicable to that case. 

Note that the standard formulas for computing the cost 
of a join plan typically take three parameters: the sizes of the 
two relations being joined and the amount of available mem- 
ory. Thus, to compute the expected cost of a join method 



applied to a particular pair of relations, we need just three 
distributions. This means that even though we may have 
many more parameters to deal with, if we apply Algorithm C 
to the multi-parameter setting, at each node only three dis- 
tributions are required to compute the LEG plan for that 
node. To be able to apply this idea inductively at every 
node in the dag, we also need to compute the distribution 
of the size of the result of the join, since the parent node 
of the current node (should there be any) needs that as the 
distribution of one of its input size. In order to compute 
the distribution of the size of the result, we need to have a 
distribution of the selectivity of the join predicates. Thus 
at each node, we need exactly four distributions — the three 
distributions for computing expected cost plus the distri- 
bution for the selectivity of the join predicate — no matter 
how many distributions we start with. Figure 1 shows the 
distributions we carry at each node and the quantity that 
depends on them. 

Here is the generic modified algorithm. As in Section 3.4, 
the algorithm works on the dag. 

Algorithm D 

To compute the LEG plan for a node at depth k-\-l la- 
beled S, consider each j £ S and let Sj = S — {j}. Let 
Bj = ixiigs^ Ai. We assume inductively that we have 
the LEG plan for Sj as well as the distribution of \Bj\. 
We also assume we have the best way to access Aj and 
the distribution of \Aj\ after any initial selection. We 
evaluate the cost formula for each triple of possible val- 
ues of M, \Bj\ and \Aj\, and use that to compute the 
expected cost of calculating Sj ixi Aj for each method. 
Taking bx to denote the number of buckets for random 
variable X, this shows that we need tiAfti|s^. |ti|Aj | eval- 
uations to compute the expected cost of a particular 
method for computing Sj txs Aj. We can compute the 
expected cost for each choice of j, and retain the plan 
of least expected cost. The total cost of this naive com- 
putation is tiM X/jes ^\Bj\^\Aj\ for each join algorithm 
considered. 

To compute the distribution for the size of the result, 
we fix a j and compute, for each triple (a, b, a) of possi- 
ble values of \Aj\, \Bj\, and selectivity a the probabil- 
ity that the join has size aba. (Since we are assuming 
independence, this is just the product of Pr(|ylj| = a), 
Pr(|_Bj| — b), and the probability that the selectivity 
is (J.) From this we can fill in the distribution for the 
size of the result. 

Thus, we require 0(6|b^. |6|Aj|6<t) operations to compute the 
distribution. Since the size of the result is independent of 
the choice of we need to do this computation for only one 
j; we can choose the j for which biBj\b\Aj\ is minimal. In 
practice, we expect that we will have 6|Aj| = ^|Sj| for ^-U jj 
so the choice will not matter. 

To summarize, the generic method given above takes 
^^gg bMbiBj\b\Aj \ evaluations of the cost formula and takes 



ba) operations to compute the distribution for 



0(&|Bj|6|Aj|6a 

\Bj tx] Aj\. Gan we do better if we have more knowledge of 
the cost formula? Most join methods used in practice have 
relatively simple cost formulas. We pick sort-merge join and 
page nested-loop join as examples, and demonstrate in the 
next two subsections that we can indeed do much better. 



3.6.1 The Case of Sort-Merge Join 

La* L = max{| A|, \ B\}; the cost of sort-merge join for Ai<i B 
isE 




if M > 

if ^ < M < \/I 
if Af < 



C(SM,v) = 

Note that 

Ec(SM) = 



We now show how the first term can be computed efficiently. 
The second term can be computed analogously; we leave the 
details to the reader. Let Ft, = E(jAj : \A\ < h) + h. Let 
Val{X) denote the representatives from the hx buckets fer 
variable X. We can rewrite the first summand as foUowsu 



1^1 


<1- 


1^1 


> 1- 



bl^Val(\B\) 



2Ft Pt{M > Vb) 
4:FiPr{\/b <M <Vb) 
6Ft Pt{M < v^) 



(1) 



We now describe how to compute E(c(SM : |yl| < \B\) 
and Pr(|A| < \B\) in time 0(6a/ + + fe|fl|)- First we 
compute Pr(M > m) for each m G Val{M). We can easily 
compute all Val{M) probabilities in time 0{bM)- We store 
these values in a table. By table lookup, we can then com- 
pute Pr(M > 6), Pr(v^ < M < 76), and Pr(M < v^), for 
each value of 6, in constant time. 

Next we compute Pr(|A| < b) for each b G Val(\B\) and 
store these values in a table. Since Pr(|yl| < b') — Pr(|A| < 
b) + Pr(6 < \ A\ < b'), for 6 < b', we can compute all of these 
probabilities in time 0(b|Aj +b\B\) (because we need only go 
through each set of buckets once). 

Then we compute E{\A\ : \A\ < b) for each b G Val{\B\) 
and store these values. Again, this can be done in time 
0(&|A| + fe|i3,), Since E(|^| : \A\ < b') = E(|^| : \A\ < 
b)Pr(\A\ < b) + E{\A\ ■.b<\A\< b')PT{b < \A\ < b') for 
b < b' (and so we only need to go through each set of buckets 
once) . 

We can now compute Ec(SM : \A\ < \B\) using 
Note we need only constant time to compute each summand, 
since for each b G V^aZ(|_B|) (since Fb can be computed by 
adding 6 to E(jyl| : \A\ < b), which we already have, and it 
takes only constant time to compute the probabilities involv- 
ing M, since they have been stored. Thus, we can compute 
the expectation in total time OipM + b\A\ + b|s|) (including 
the time it take to compute all the values we have stored in 
the tables). 

Finally, we need to compute Pr(|yl| < \B\). This can be 
done in time 0{b\B\), since 



Pr(l^| < \B\) 



E 

6GVai(|S| 



Prd^l <b)Pr(lBl = b), 



and we have already computed Pr(|^| < b). 



Our formulas co 
ysis presented in 



I/O costs only and are based on the anal- 
, simplified to three cases. Commercial 



database systems use more complicated formulas, usually represented 
in the form of complex code. These arc sometimes the result of aim- 
ing for too much accuracy when modeling the algorithm, despite the 
fact that the parameters used to instantiate the model are inaccurate. 
We speculate that a return to simple formulas in combination with 
LEC optimization may result in more reliable query optimizers. 

■^We write X — a: as an abbreviation for the statement "X takes 
on a value in the bucket whose representative is x" . 



The whole computation takes time OipM + b\A\-'rb\B\), so 
the algorithm we informally described is linear in the total 
number of buckets. Note that this algorithm is (asymptoti- 
cally) optimal, since we must at least look at the entries in 
the individual distributions. 

We need to carry out this computation for every node 
in the dag. (The A and B above become Bj and Aj, using 
our earlier notation.) Note that some of the cost can be 
amortized over the nodes. We need to do the computation 
of Pr(M > m) for m G Val{M) and and Pr{Aj < a) for 
a G Val{Aj), j = 1, . . . ,n only once, since these probability 
distributions do not change over the course of the execution. 
If we precompute these values, then the amount of work at 
each node is only 0{b^Bj\) (for sort-merge). 

3.6.2 The Case of Nested-Loop Join 

As another example, we look at the nested-loop join method. 
Let S — min{|^|, The cost formula for A :xs B using 

nested-loop join is: 



C(NL,v) 



\A\ + \B\ ■dM>S + 2 

\A\ + \A\-\B\ ■dM<S + 2 



As in the previous section, we split Ec(NL) into two terms: 
E(c(NL : 1^1 < |B|)Pr(|A| < \B\) and E(c(NL : \A\ > 
|i3|)Pr(|A| > \B\). Again we focus on the first term and 
leave the second term to the reader. Let Ga = E(|_B| : 
o- < I^D) for 1 £ yaZ(l^l). Note that the first term can be 
rewritten as follows: 



E 

a£Val(\A\) 



Pri\A\ = a) 



{a + Ga)Pr{M> a + 2) + 
{a + aGa)Pr{M <a + 2) 



(2) 



As before, we can do the computation in time OipM + b| a| + 
b\B\)- The procedure is very similar to that for sorted-merge 
join, so we just sketch the details here. 

We again compute Pr(M > m) for each m G Val{M). 
This takes 0{bM) steps and enables us to compute Pr(M > 
a -f 2) in a constant number of steps. Next we compute 
Pr(a < \B\) for each a G FaZ(|A|). As before, we can com- 
pute all Fa/(|A|) probabilities in time 0{b\A\ + ^|s|)- Then 
we compute E(|B| : a < \B\) for each a G Va/dAl). Argu- 
ments similar to those used in the sort-merge case show that 
this can be done in time 0(fe|A| + b\B\)- We can then com- 
pute Ec(NL : \A\ < \B\) using Again each summand 
only requires constant time, since we already have Ga and 
we can determine the probabilities involving M in a constant 
number of steps. Finally, we can compute Pr(|^| < \B\) in 
time 0{b\A\), just as in the case of sort-merge. 

The whole process again takes time 0{bM + b^A\ + b\B\), 
so the algorithm is linear in the (total) number of iDuckets. 

As before, we only considered a single node in the dag. 
If we precompute Pr(M > m) and Pr(i3 > b), then the 
amount of work at each node for nested- loop is 0{b\A\)- 

3.6.3 The Distribution of the Result Size 

We showed that the expected cost of specific join methods 
can be computed in time linear to the number of buckets. 
However, recall that we also need to compute the distri- 
bution for the size of the result at each node. This takes 



time 0{b^A\b\B\bcr)- Can we do better? Again, for spe- 
cific distributions, it may be possible. However, we can say 
more. Suppose for uniformity we decide to have b buck- 
ets at every node for each variable. If we have 6 buckets 



for each of the variables \A\, \B\, and a, then we can get 
as many as buckets for the size of the join A txi B. To 
maintain b buckets, we would have to "rebucket" after com- 
puting the probability. Instead of rebucketing after doing 
the computation, we can rebucket each of \A\, \B\, and a 
so that they have buckets. Then the whole computa- 
tion takes time 0{b), as desired, and we have b buckets for 
\A CXI B\. More generally, if we rebucket each of \B\, 



and a so that they have 



and \i%T buckets, 



respectively, then we can carry out the computation in time 

0{^b\A\b\B\bcT+b\A\ +b\B\ +b^) = 0(b|A| +b\B\ +b^) steps. 

3.7 Strategies for Partitioning the Parameter Space 

As we have seen, the complexity of all our algorithms to 
computing or approximating the LEG plan depends on par- 
titioning the parameter space into a number of buckets. A 
large number of buckets gives a closer approximation to the 
true probability distribution, leading to a better estimate 
of the LEG plan. On the other hand, a smaller number of 
buckets makes the optimization process less expensive. (As 
we mentioned earlier, the algorithm with one bucket reduces 
to the standard System R algorithm.) For specific examples 
(such as Example choosing the buckets is straightfor- 
ward, as a function of the join algorithms being considered 
and the sizes of the relations being joined. We do not yet 
have a general mechanism for choosing buckets optimally 
and efficiently. However, we have insights that should help 
us explore this issue in future work. 



Gonsider our first two algorithms (Sections 3.2 and 3.S) 
which used the System R algorithm on a number of param- 
eter settings to generate candidate plans, and then evalu- 
ated each of these candidates to find the one of least ex- 
pected cost. The partitioned parameter distributions are 
used in two ways: the first is to generate candidate plans 
(by computing the best plan or c best plans for each pa- 
rameter value considered) and the second is in computing 
the actual expected cost of the candidates generated. Dif- 
ferent, but related, issues arise in each case. When gener- 
ating candidates, we are basically interested in determining 
the region of parameter space in which to search for good 
candidates. We can partition it coarsely at first, and then 
generate more candidates in the region of parameter space 
that seems most likely to contain the best candidates. When 
computing costs, recall that our goal is to find the candidate 
of least expected cost. We do not always need an extremely 
accurate estimate of the cost to do this. We expect to be 
able to associate a degree of accuracy with each particu- 
lar partitioning — that is, a guarantee that the estimated 
expected cost of a plan using this partitioning is within a 
certain degree of the true expected cost. We may be able to 
use coarse bucketing to eliminate many plans and then use 
a more refined bucketing to decide among the remaining few 
plans. 

This insight applies even more to our third algorithm 
(Section which actually computes the LEG plan. If 

there are j algorithms being compared at a given node in the 
dag, the expected cost of only one of them (the algorithm 
of least cost) needs to be computed accurately, since the 
other plans are pruned. With respect to the pruned plans, 
we simply need to be satisfied that their expected costs are 
higher than the chosen plan. Gonsequently, we can start 
with a coarse bucketing strategy to do the pruning, and 
then refine the buckets as necessary. 

Moreover, note that we do not have to use the same par- 
titioning strategy at every node. We should use the partition 



appropriate to the strategies being considered at that node. 
The cost formulas of the common join algorithms are very 
simple, at least with respect to a parameter like available 
memory. As we saw, for fixed relation sizes, the cost for 
a sort-merge join has one of three possible values, depend- 
ing on the relationship between the memory and the size of 
the larger relation; similarly, the cost of a nested-loop join 
has only one of two possible values. Gonsequently, if we 
are considering a sort-merge join (resp., nested-loop join) 
for fixed relation sizes, we need deal with only three (resp., 
two) buckets for memory sizes. In general, we expect that 
we will be able to use features of the cost formulas to reduce 
the number of buckets needed on a per-algorithm per-node 
basis. 

Another way to approach bucketing is to realize that, 
ultimately, we want to compute the expected cost. Fix a 
plan P. Note that we can express E(d(P) as follows; 

oo 

Ec(P) = ^cPr(C(P,v) = c). 

c=0 

For a fixed c, values of v that yields G(P, v) = c are called a 
level set of (D(P,v). If the cost of P has relatively few level 
sets, then it may be wise to bucket the parameter space with 
these level sets in mind. Suppose C(P, v) has £ level sets. In 
principle, we can compute Ec(P) with £ evaluations sf the 
cost function, £ multiplications, and £ — 1 additions.u We 
can do this if we have the probabilities for each level set. In 
general the buckets will not correspond to level sets and we 
may evaluate the cost function many times only to get the 
same answer each time. So if we bucket the joint distribution 
by using the level sets (instead of bucket each parameter 
separately), we can minimize the computation involved in 
computing the expected cost. The cost function may have 
many level sets. If we are willing to settle for an approximate 
answer, we can bucket the range of the function, thereby 
coalescing some of the level sets. One problem with this 
approach is that the probability of each level set may not be 
easy to determine. 

4 Concluding Remarks 

This paper presents the simple idea of searching for query 
execution plans with the least expected cost. To the best 
of our knowledge, this is a new approach to query optimiza- 
tion, departing from the established approach used for the 
past two decades. Our approach can be viewed as a gener- 
alization of the traditional approach in the sense that the 
traditional approach is essentially our approach restricted 
to one bucket (in the static case). Although this paper pro- 
poses the approach, we are aware that many details need 
to be worked out. To make our task easier, we have made 
simplifying assumptions. We now revisit some of these as- 
sumptions. 

• Our presentation of the System R query optimization 
algorithm is rather simplistic. The major issue we do 
not consider is parallelism, which can play a role in 
two ways (either through bushy join trees or through 
pipeline parallelism). In both cases, there is an in- 
teraction between the parallel components in terms of 
memory used. While we have ignored this issue, cur- 
rent query optimizers do model it, and we believe the 



This is also a lower bound, if we want the exact expected cost 
(and if we treat the cost function as a black box). 



same techniques can be applied to LEG optimization 
as well. 



[Loli98] 



Guy Lohman, 1998. Personal communication 
with Praveen Seshadri. 



• In dealing with changes during the execution of the 
plan, we made the simplifying assumption that no 
change occurs during any one join "phase". This is 
clearly an approximation of reality. Further, pipelined 
joins should be treated together as a single phase while 
other algorithms (like a sort-merge join) may involve 
multiple phases. While we have certainly made sim- 
plifying assumptions here, we note that our approach 
at least allows us to tackle a problem not addressed by 
other works in this area. 

• When we considered multiple parameters, we assumed 
that the parameters were independent. This may not 
always be a reasonable assumption in practice. It 
would be of interest to see to what extent we could ex- 
tend our techniques to situations were there are some 
dependencies between the variables. 

Although there is clearly work that needs to be done before 
we can use LEG query optimization in production database 
systems, we believe that it is an approach well worth ex- 
ploring.^ We are currently prototyping the algorithm of Sec- 



[PHH92] 



tion 3.4 to test its benefits against realistic queries and ex- 
ecution environments. Such a prototype will also be useful 
to investigate the impact of bucket choice (see Section p. 7] ) 
on the quality of LEG plans. 
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